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Abstract 


This specification updates the current recommendation for the use of the Transport Layer 
Security (TLS) protocol to provide confidentiality of email between a Mail User Agent (MUA) and 
a Mail Submission Server or Mail Access Server. This document updates RFC 8314. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc8997. 


Copyright Notice 


Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. Code Components extracted from this document must include 
Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Simplified BSD License. 
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1. Introduction 


[RFC8314] defines the minimum recommended version of TLS as version 1.1. Due to the 
deprecation of TLS 1.1 in [RFC8996], this recommendation is no longer valid. Therefore, this 
document updates [RFC8314] so that the minimum version for TLS is TLS 1.2. 


2. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


3. Updates to RFC 8314 
OLD: 


4.1. Deprecation of Services Using Cleartext and TLS Versions Less Than 1.1 


NEW: 
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4.1. Deprecation of Services Using Cleartext and TLS Versions Less Than 1.2 


OLD: 


As soon as practicable, MSPs currently supporting Secure Sockets Layer (SSL) 2.x, SSL 
3.0, or TLS 1.0 SHOULD transition their users to TLS 1.1 or later and discontinue support 
for those earlier versions of SSL and TLS. 


NEW: 


As soon as practicable, MSPs currently supporting Secure Sockets Layer (SSL) 2.x, SSL 
3.0, TLS 1.0, or TLS 1.1 SHOULD transition their users to TLS 1.2 or later and discontinue 
support for those earlier versions of SSL and TLS. 


In Section 4.1 of [RFC8314], the text should be revised from: 


OLD: 


One way is for the server to refuse a ClientHello message from any client sending a 
ClientHello.version field corresponding to any version of SSL or TLS 1.0. 


NEW: 


One way is for the server to refuse a ClientHello message from any client sending a 
ClientHello.version field corresponding to any version of SSL or TLS earlier than TLS 1.2. 


OLD: 


It is RECOMMENDED that new users be required to use TLS version 1.1 or greater from 
the start. However, an MSP may find it necessary to make exceptions to accommodate 
some legacy systems that support only earlier versions of TLS or only cleartext. 


NEW: 
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It is RECOMMENDED that new users be required to use TLS version 1.2 or greater from 
the start. However, an MSP may find it necessary to make exceptions to accommodate 
some legacy systems that support only earlier versions of TLS or only cleartext. 


OLD: 


If, however, an MUA provides such an indication, it MUST NOT indicate confidentiality 
for any connection that does not at least use TLS 1.1 with certificate verification and also 
meet the minimum confidentiality requirements associated with that account. 


NEW: 


If, however, an MUA provides such an indication, it MUST NOT indicate confidentiality 
for any connection that does not at least use TLS 1.2 with certificate verification and also 
meet the minimum confidentiality requirements associated with that account. 


OLD 


MUAs MUST implement TLS 1.2 [RFC5246] or later. Earlier TLS and SSL versions MAY 
also be supported, so long as the MUA requires at least TLS 1.1 [RFC4346] when 
accessing accounts that are configured to impose minimum confidentiality 
requirements. 


NEW: 


MUAs MUST implement TLS 1.2 [RFC5246] or later, e.g., TLS 1.3 [RFC8446]. Earlier TLS 
and SSL versions MAY also be supported, so long as the MUA requires at least TLS 1.2 
[RFC5246] when accessing accounts that are configured to impose minimum 
confidentiality requirements. 


OLD: 


The default minimum expected level of confidentiality for all new accounts MUST 
require successful validation of the server's certificate and SHOULD require negotiation 
of TLS version 1.1 or greater. (Future revisions to this specification may raise these 
requirements or impose additional requirements to address newly discovered 
weaknesses in protocols or cryptographic algorithms.) 
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The default minimum expected level of confidentiality for all new accounts MUST 
require successful validation of the server's certificate and SHOULD require negotiation 
of TLS version 1.2 or greater. (Future revisions to this specification may raise these 
requirements or impose additional requirements to address newly discovered 
weaknesses in protocols or cryptographic algorithms.) 


4. IANA Considerations 


This document has no IANA actions. 


5. Security Considerations 


The purpose of this document is to document updated recommendations for using TLS with 
email services. Those recommendations are based on [RFC8996]. 
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